Product development and design can be a complex process. One example of such a complex task is the engineering of software. A software development project can involve as few as one person, or as many as hundreds. Development work may be done by a tightly-knit team working in a highly-directed fashion, or may involve coordination amongst many disparate developers, engineers, programmers, managers, and marketers spread over long geographical distances. Additionally, many large-scale development projects are of a complexity rarely seen in other fields. The number of operations in a large piece of software can be greater than even the number of different mechanical parts in a large piece of machinery, such as a plane. This complexity makes detection of errors very difficult, and because many errors can effectively “hide” until special circumstances occur, special error detection techniques often have to be employed to ensure software will operate predictably and correctly. The unique nature of the problem makes it difficult for project managers, when making decisions about the software engineering process, to accurately predict results. This, in turn, makes it very difficult to see the possible success or failure of different processes which may be under consideration and to properly design a development process which will result in the most-efficient and/or highest-quality end product.
To better improve software engineering, and to encourage consistency and predictability in development, generalized software development models have been proposed which prescribe generic methods of developing software. Examples of these models include, but are not limited to: the waterfall model, the rational unified process model, the spiral model, rapid prototyping, and the IEEE 12207 software development standard and others. While some of these models are well known, and while they do provide guidance, they do suffer from flaws. The first is that not every software development project fits easily into one of the existing prescribed development models. Trying to shoehorn a project into a model for which it is not ideally suited may frustrate the efforts of the software developer, and may waste time and resources before even a single requirement is determined. One reason for this is that many models end up forcing developers into a particular development mold rather than to describe a given development situation or to allow developers flexibility to modify and improve the model to best suit their needs.
One example of such an ill fit is the use of the waterfall model under circumstances where there are requirements changes late in the development cycle. This situation may occur when users have only a little familiarity with the type of system that is being proposed and later change their mind, uncovering new requirements late in the development cycle. The use of a waterfall process in this situation, with its strictly-defined sequence of development stages, is problematic because changes cannot be easily incorporated and users to not see a prototype until very late in the development process. A better fit in this situation would be rapid prototyping, where a prototype is put into users hands early, allowing users to clarify what they want. Indeed, many currently-used software development models are based on the waterfall model, with additional modifications made for particular types of development problems. However, this ever-expanding universe of software development models, while meant to broaden the tools available to a software engineer, serves instead to force the engineer to choose between increasingly-narrow development niches, none of which may serve his or her actual needs.
In order to provide a more robust experience, some work has been done to develop software process simulation models (“SPSMs”), which can simulate the activity of software development, utilizing known or discovered relations between software development inputs, such as manpower, quality control review, and time, and outputs such as cost, time and quality. Unfortunately, while a properly-designed SPSM can predict some results for a given modeled software development process, these models are often difficult and time-consuming to create for each process. Additionally, these models, as they are designed to incorporate the complete aspects of a software development process, often require the acquisition of software development metrics data that is difficult to acquire, or may not yet exist. While the problems discussed herein are found in software engineering, they are not specific to that particular product development. In fact, difficulties like these exist for other forms of product development, including, but not limited to, hardware and systems engineering. Some of the same activities in these engineering scenarios, such as design, requirements, analysis, development, and testing, are similar to activities performed in software engineering.
What is needed is a system that provides flexible simulation model creation tools which can quickly be developed or modified for a given system.